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AUTOMOBILE ET DES CALCULATEURS EMBARQUES. 

(57) L'invention propose un procede et un dispositif de 
communication entre un equipement (30) exterieur a un ve- 
hicle automobile (1) d'une part et des calculateurs embar^ 
ques (10) relies entre eux par au moins un bus CAN (11) 
d'autre part, dans lequel requipement (30) est connects a 
un bus USB (31), dans lequel un module de couplage (20) 
est connecte au bus CAN (1 1) de maniere a eviter la gene- 
ration de reflexions electriques sur.celui-ci et forme passe- 
relle entre le bus CAN (1 1 ) et le bus USB (31 ), en vue de la 
transmission de trames CAN entre requipement (30) et les 
calculateurs (10) en sorte qu'un programme d'application 
s'executant dans requipement (30) est vu sur le bus CAN 
(1 1 ) comme un abonne CAN. 
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PROCEDE ET D1SPOSITIF HE COMMUNICATION ENTRE UN 
EQU1PEMENT FXTERIEUR A UN VEHI CULE AUTOMOBILE 
FT PES CALCULATEURS EMBARQUES 

5 . La presente invention se rapporte a un procede et a un dispositif de 
communication entre un equipement exterieur a un vehicule automobile et des 
calculateurs embarques. 

Elle s'applique au domaine des systemes electroniques pour 
I'automobile, et en particulier a celui des systemes de diagnostic embarque ou 
10 systemes OBD (de I'anglais « On Board Diagnostic »). Les vehicules 
automobiles comprennent de plus en plus de calculateurs dedies a la gestion 
de fonctions determinees telles que le controle moteur, le freinage, la 
transmission, Pessuyage des vitres, la climatisation ou le 
chauffage/ventilation, etc... Afin d'alleger les liaisons electriques a bord du 
15 vehicule, ces calculateurs sont relies entre eux par un ou plusieurs bus de 
donnees, notamment de type CAN (de I'anglais « Controller Area Network »). 
La mise en ceuvre d'un bus CAN respecte les specifications de la Norme ISO 
n° 11898 version V2.0A (version standard) ou V2.0B (version etendue) du 
15/11/1993 et de son amendement n° 1 du 01/04/1995 (ci-apres la norme 
20 CAN). Sur requete, les calculateurs embarques peuvent emettre sur le bus 
CAN des messages de diagnostic embarque, ci-apres messages OBD, selon le 
protocole du bus CAN, pour signaler des defauts ou des dysfonctionnements. 

Dans I'etat de la technique, un systeme de diagnostic embarque 
comprend une station de diagnostic distante, comme etant exterieure au 
25 vehicule, qui peut etre reliee a un calculateur determine du vehicule par 
rintermediaire d'une ou de plusieurs liaisons de type serie, en general 
specifiques du constructed du vehicule, et proches de la norme RS232C. Ce 
calculateur, qui est par ailleurs dedie a la gestion d'une fonction determinee du 
vehicule, comporte une prise de diagnostic sur laquelle un cable supportant la 
30 liaison de type serie peut etre connecte de maniere a relier le calculateur a la 
station de diagnostic. II comporte en outre des moyens pour recevoir les 
messages OBD selon le protocole du bus CAN en provenance de tous les 
autres calculateurs. et pour emettre des informations de diagnostic vers la 
station de diagnostic via la liaison de type serie, selon un protocole prqpre a 
35 cette liaison. 
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Toutefois, un tel systeme n'est pas pleinement satisfaisant dans la 
mesure ou tous les messages OBD doivent etre traites par ledit calculateur 
determine, qui doit pour ce faire disposer d'une capacite de traitement adaptee, 
et est done complexe et couteux. 
5 C'est pourquoi il serait avantageux de pouvoir relier la station de 

diagnostic distante directement au bus CAN afm qu'elle puisse recevoir les 
messages OBD emis par les calculateurs selon le protocole du bus CAN et non 
des informations de diagnostic qui en sont derivees. 

Toutefois, le bus CAN est constitue par une ligne differentielle adaptee 
10 en impedance a chacune de ses extremites, a laquelle les abonnes 
(calculateurs) sont relies par un troncon de cable (« Cable Stub», selon la 
terminologie de la norme CAN). Selon les prescriptions de la norme CAN, la 
longueur d'un tel.tro.n90n de cable ne doit pas etre superieure a 30 centimetres 
pour limiter la generation de reflexions electriques sur le bus CAN. II n'est done 
15 pas possible de relier de cette fa?on la station de diagnostic au bus CAN, 
sachant que la longueur de cette liaison est typiquement de I'ordre de 4 
metres. En effet, les reflexions electriques engendrees sur le bus CAN 
mettraient en cause la fiabilite du transfert des donnees, en particulier pour les 
transferts a haut debit (600 Kbits/s) requis pour le diagnostic. 
20 Un bus USB (de I'anglais « Universal Serial Bus ») est un bus de type 

serie qui fait I'objet d'une specification commune elaboree par les societes 
Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, et 
NEC Corporation, et dont la derniere revision 1.1 est datee du 23 septembre 
1998 (ci-apres la specification USB). C'est un bus de type maTtre/esclave, a 
25 repartition de bande passante, sans gestion de priorite des messages. Dans la 
terminologie de la specification USB, le maTtre est appele un hote (« host » en 
anglais) et les esdaves sont appeles des dispositifs (« devices » en anglais) 
soit de type fonctionnel soit de type repeteur. Selon la terminologie de la 
specification USB, les premiers dispositifs sont appeles « functions » et les 
30 seconds sont appeles « hub ». L'hote est un ordinateur hote dans lequel est 
installee une interface USB (« host controller » selon la terminologie de la 
specification USB). II comprend une plate-forme materielle (unite centrale de 
calcul, bus interne, memoire vive, etc..) et un systeme d'exploitation. Un 
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dispositif fonctionnel assure une fonctionnalite de I'hote. II s'agit d'une unite 
peripherique telle qu'une souris, des hauts parleurs, etc... ou d'une connexion 
exterieure telle d'une connexion RNIS. Un dispositif r6p6teur permet la 
connexion d'autres dispositifs au bus USB. L'unite de donnees manipulee par 
le protocole du bus USB est appelee un paquet (ci-apres paquet USB). Un 
paquet USB comporte trois elements : un en-tete contenant des informations 
de commande (par exemple la source, la destination et la longueur du paquet), 
les informations utiles a transmettre, et des bits de detection et de correction 
d'erreur. 

A I'inverse, le bus CAN est de type multi-maTtre, a temps de latence 
garanti, avec une gestion de priorite des messages permettant un arbitrage en 
cas de conflit d'acces. Uunite de donnees manipulee par le protocole du bus 
CAN est appelee une trame (ci-apres trame CAN). 

[.'invention a pour objet de permettre a un equipement distant tel qu'une 
station de diagnostic exterieure au vehicule, de recevoir les messages OBD 
emis par les calculateurs embarques selon le protocole du bus CAN, sans 
encourir le risque de reflexions electriques sur le bus CAN. 

Ce but est atteint, conformement a I'invention, grace a un procede de 
communication entre un equipement exterieur a un vehicule automobile d'une 
part et des calculateurs embarques relies entre eux par au moins un bus CAN 
d'autre part, comprenant les etapes consistant a : 

- encapsuler, au niveau de I'equipement ou au niveau d'un module de 
couplage connecte d'une part au bus CAN de maniere a eviter la generation de 
reflexions electriques sur celui-ci et d'autre part a un bus USB, une trame CAN 
emise selon le protocole du bus CAN par Pequipement ou par un calculateur 
respectivement, dans au moins un paquet USB selon le protocole du bus USB ; 

- emettre, via le bus USB, le paquet USB vers le module de couplage ou 
vers Pequipement respectivement ; 

- recevoir, au niveau du module de couplage ou au niveau de 
Tequipement respectivement, le paquet USB et le decapsuler pour en extraire 
la trame CAN, 

en sorte qu'un programme d'application s'executant dans Tequipement 
est vu sur le bus CAN comme un abonne CAN. 
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L'equipement etant par exemple un ordinateur comprenant par 
construction des moyens de gestion d'un bus USB on peut ainsi realiser a 
faible cout un dispositif de communication entre l'equipement et les 
calcuiateurs embarques. 

5 En effet, I'invention propose egalement un dispositif de communication 

entre un equipement exterieur a un vehicule automobile d'une part et des 
calcuiateurs embarques relies entre eux par au moins un bus CAN d'autre part, 
dans lequel l'equipement est connecte a un bus USB, le dispositif comprenant 
un module de couplage connecte d'une part audit bus CAN de maniere a eviter 

1 0 la generation de reflexions electriques sur celui-ci et d'autre part audit bus USB 
et comprenant des moyens pour transmettre, via le bus USB, des trames CAN 
entre l'equipement et les calcuiateurs de maniere qu'un programme 
d'application s'executant dans l'equipement est vu suf le bus CAN comme un 
abonne CAN. 

15 L'invention propose en outre un systeme de diagnostic embarque pour 

vehicule automobile comprenant : 

- des calcuiateurs embarques, relies entre eux par au moins un bus CAN 
et pouvant envoyer ou recevoir par I'intermediaire dudit bus CAN des 
messages de diagnostic embarque sous la forme de trames CAN ; 

20 - une station de diagnostic exterieure au vehicule automobile, reliee a un 

bus USB ; 

- un dispositif de communication tel que defini ci-dessus, de maniere 
qu'un programme d'application s'executant dans la station de diagnostic est vu 
sur le bus CAN comme un abonne CAN. 

25 D'autres caracteristiques et avantages de I'invention apparaltront encore 

a la lecture de la description qui va suivre. Celle-ci est purement illustrative et 
doit etre lue en regard des dessins annexes, sur lesquels on a represents : 

- a la figure 1 , le schema d'un systeme selon I'invention ; 

-a la figure 2, le schema de la topologie d'un premier mode de 
30 realisation d'un dispositif selon I'invention ; 

- a la figure 3, le schema fonctionnel d'un module de couplage selon 

I'invention ; 
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- a la figure 4, le schema de la topologie d'un second mode de 
realisation d'un dispositif selon I'invention. 

Dans la presente description et aux figures, les memes elements portent 

les memes references. 

5 A la figure 1, on a represente le schema d'un systeme selon I'invention. 

Un vehicule automobile 1 comprend une pluralite de calculateurs embarques 
10 qui assurent respectivement la gestion d'une fonction determinee telle que 
le controle moteur (par exemple un calculateur pour I'injection d'essence), le 
freinage (par exemple un calculateur pour un systeme d'anti-blocage des roues 

10 dit ABS de I'anglais « Anti-Blocking System »), la climatisation, la transmission 
automatique, etc... Les calculateurs -10 sent relies entre.eux par un bus CAN 
portent la reference 11. Plus particulierement, chaque calculateur est relie au 
bus CAN par I'intermediaire d'une prise d'interconnexjbn 13 et d'un troncon de 
cable 14. 

15 Un equipement 30 exterieur au vehicule 1, tel qu'une station de 

diagnostic, est relie a un bus de type serie determine portent la reference 31 . 
En pratique, le bus 31 est supporte par un cable, de preference protege des 
rayonnements electromagnetiques, dont la longueur est superieure a 30 
centimetres et peut atteindre 4 metres. L'equipement est done distant du bus 
20 CAN et de ses calculateurs. Une station de diagnostic se presente 
classiquement sous la forme d'un ordinateur de type PC (de I'anglais 
« Personel Computer ») dans lequel est execute un programme duplication 
ad-hoc sous la commande d'un operateur. C'est pourquoi le bus 31 est de 
preference un bus USB. En effet, les materiels et les logiciels permettant la 
25 gestion d'un bus USB sont la plupart du temps deja presents dans les 
ordinateurs de type PC actuellement disponibles. Le choix d'un bus USB pour 
le bus 31 est done avantageux car il permet la realisation d'un dispositif de 
communication entre l'equipement 30 et les calculateurs 10 qui soit de faible 
cout. 

30 Selon i'invention, un tel dispositif comprend un module de couplage 20 

connecte au bus CAN de maniere a eviter la generation de reflexions 
electriques sur celui-ci. Le module 20 etant plus particulierement relie au bus 
CAN par I'intermediaire d'un troncon de cable 28 et d'une prise 
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d'interconnexion ou prise de diagnostic 21 (voir figure 2), la norme CAN indique 
que ceci est obtenu en faisant en sorteque la longueur du troncon de cable 28 
soit au plus egale a 30 centimetres. Dit autrement, le module 20 est situe a 
proximite du bus CAN, cette notion de proximite et celle de distance devant 
5 etre interpreters a la lumiere de la norme CAN. En pratique, le module 20, qui 
comporte des elements materiels et des elements logiciels, est implante de 
maniere fixe ou amovible a I'interieur du vehicule 1 , par exemple sous le capot 
moteur. de maniere a etre faciiement accessible. Pour proceder a une 
operation de diagnostic, la station de diagnostic 30 est approchee du vehicule 
10 1 et le cable 31 est relie a la prise de diagnostic 21. Le programme 
d'application est alors execute dans la station-de diagnostic. Celle-ci transmet 
des messages OBD selon le protocole du bus CAN pour requerir la 
transmission en reponse, par les calculateurs 10, de. messages OBD selon le 
protocole du bus CAN. Les messages OBD contiennent des informations de 
15 diagnostic et sont transmis sous forme de trames CAN entre la station de 
diagnostic 30 et les calculateurs 10 via le bus USB. 

A la figure 2, on a represents schematiquement la topologie d'un 
dispositif de communication selon un premier mode de realisation. 

Le bus CAN 11 presente une forme generate rectiligne. II s'agit en 
20 pratique d'une ligne differentielle refermee a chacune de ses extremites 12 par 
une impedance de 120 Ohms. De la sorte, I'impedance du bus CAN est, aux 
defauts d'adaptation pres, constante sur toute la ligne et egale a 60 Ohms. Les 
calculateurs 1 0 et le module de couplage 20 sont connectes au bus CAN de 
maniere a eviter la generation de reflexions electriques, par I'intermediaire de 
25 troncons de cable respectivement 14 et 28 et d'une prise d'interconnexion 
respectivement 13 et 21. La prise 21, aussi appelee prise de diagnostic, peut 
etre situee a une des extremites 12 du bus CAN 31, ou entre ces deux 
extremites. Le module de couplage 20 est un abonne du bus CAN, au meme 
titre que les calculateurs 10. II est aussi un dispositif fonctionnel du bus USB, 
30 dont I'hote est I'equipement 30. II remplit une fonction de passerelle entre le 
protocole du bus CAN et celui du bus USB. De preference, le module de 
couplage 20 est connecte au bus CAN par I'intermediaire d'une prise de 
diagnostic 21 situee a une extremite 12 du bus CAN . 
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Deux liaisons logiques unidirectionnelles sont etablies, via le bus USB, 
entre le module de couplage 20 et I'equipement 30, £ raison d'une pour chaque 
sens de transmission. Pour decrire ces liaisons logiques, il est necessaire 
d'introduire la notion de point terminal. 
5 Un point terminal (« endpoint » selon la terminologie de la specification 

USB), est une abstraction du protocole du bus USB designant une portion d'un 
dispositif USB reperee par une adresse unique, qui delivre ou collecte les 
informations d'un flot d'informations entre I'hote et ledit dispositif USB. L'hote et 
les dispositifs USB comportent chacun un point terminal bidirectionnel pour la 

10 transmission d'informations de controle (le « endpoint » 0 ) et au moins quatre 
points terminaux unidirectionnels pour la transmission des paquets USB (les 
« endpoints » 1 a 4). Dans un exemple le « endpoint » 1 est utilise pour le 
transfert de donnees, via le bus USB, du module de couplage 20 (dispositif 
USB) vers I'equipement 30 (hote), alors que le « endpoint » 2 est utilise pour le 

15 transfert de donnees, via le bus USB, de I'equipement 30 (hote) vers !e module 
de couplage 20 (dispositif). 

Dans le cas d'un dispositif selon un second mode de realisation, dont la 
topologie est representee par le schema de la figure 4, les calculateurs 
embarques 10 sont relies entre eux par I'intermediaire de deux bus CAN 

20 independants Tun de Tautre, portant respectivement la reference 11a et la 
reference 11b. Le dispositif comprend alors un premier module de couplage 
20a connecte au premier bus CAN 11a d'une part et a une branche 31a du bus 
USB 31 d'autre part, et un second module de couplage 20b connecte au 
second bus CAN 11b d'une part et a. une autre branche 31b au bus USB 31 

25 d'autre part. Les branches 31a et 31b sont des liaisons point a point entre 
respectivement le module de couplage 20a ou 20b d'une part, et un dispositif 
repeteur 33 incius dans I'equipement 30 d'autre part. En pratique, ces deux 
liaisons sont associees dans, un unique cable a plusieurs fils. Selon la 
terminologie de la specification USB, ce dispositif repeteur 33 est appele 

30 repeteur de racine (« root hub »). Chaque module de couplage 20a ou 20b est 
un abonne du bus CAN 11a ou 11b respectivement et d'autre part un dispositif 
fonctionnel du bus USB 31. II remplit une fonction de passerelle entre le 
protocole du bus CAN 1 1a ou 1 1 b respectivement, et celui du bus USB 31. 
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Dans ce cas, deux liaisons logiques unidirectionnelles sont etablies 
entre une premiere paire de points terminaux unidirectionnels de I'equipement 
et la paire de points terminaux unidirectionnels correspondants du premier 
module de couplage 20a a raison d'une liaison logique unidirectionnelle par 
5 sens de transmission. Dans un exemple, la configuration des points terminaux 
unidirectionnels est la suivante : le « endpoint » 1 de I'equipement 30 et celui 
du premier module de couplage 20a sont utilises pour le transfert de donnees 
via le bus USB 31 du premier module de couplage 20a vers I'equipement 30 ; 
le « endpoint » 2 de I'equipement 30 et celui du premier module de couplage 
10 20a sont utilises pour le transfert de donnees via le bus USB 31 de 
I'equipement 30 vers le premier module.de couplage 20a ; le « endpoint » 3 de 
I'equipement 30 et celui du second module de couplage 20b sont utilises pour 
le transfert de donnees via le bus USB 31 du second module de couplage 20b 
vers I'equipement 30 ; et enfin, le « endpoint » 4 de I'equipement 30 et celui du 
15 second module de couplage 20b sont utilises pour le transfert de donnees via 
le bus USB 31 de I'equipement 30 vers le second module de couplage 20b ; 
bien entendu, le « endpoint » 0 de I'equipement 30,. celui du premier module de 
couplage 20a et celui du second module de couplage 20b sont utilises pour le 
transfert bidirectionnel d'informations de controle entre I'equipement 30 d'une 
20 part et les modules de couplage respectivement 20a et 20b d'autre part. 

La specification USB prevoit que chaque point terminal unidirectionnel 
peut etre programme de maniere a delivrer ou collecter des paquets USB dont 
la taille est egale a 8, 16, 32 ou 64 octets (pour I'element comportant les 
informations utiles). Compte tenu de la taille d'une trame CAN, chaque trame 
25 CAN pouvant vehiculer de 0 a 8 octets de donnees en plus de I'en-tete, la taille 
optimale d'un paquet USB est egale a 16 octets. C'est pourquoi, selon une 
caracteristique avantageuse de I'invention, chaque point terminal 
unidirectionnel du bus USB est de preference programme en sorte que la taille 
des paquets USB qu'il delivre ou coilecte soit egale a 16 bits. 
30 Selon une autre caracteristique avantageuse de I'invention, le ou les 

modules de couplage sont alimentes en energie electrique par I'intermediaire 
du bus USB. Cela evite une alimentation a partir de la batterie du vehicule 
automobile 1, qui necessiterait des raccordements specifiques appropries. On 
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notera que les modules de couplage n'intervenant que lors des operations de 
diagnostic embarque, ils n'ont en effet besoin d'etre alimentes que lorsque le 
cable 31 supportant le bus USB est mis en place pour une telle operation de 
diagnostic embarque. 
5 La specification USB definit plusieurs modes de transfert de donnees sur 

le bus USB, suivant la nature et le debit des donnees a transmettre. Dans la 
terminologie de la specification USB, il s'agit des modes de transfert dits 
« Control », « Isochronous », « Interrupt » et « Bulk ». Les donnees a 
transmettre etant ici des messages OBD (contenant des donnees relatives au 

10 diagnostic) avec un debit relativement important (de I'ordre de 600 Kbits/s), le 
mode de transfert. qui convient Je _mieux_estje_mpd.e dlt «.Bulk ». Done de 
preference le mode de transfer! sur le bus USB 31 est le mode dit « Bulk ». 

Sur un bus USB, un dispositif fonctionnel ne petit pas prendre ('initiative 
d'un transfert de donnees. C'est pourquoi la specification USB definit un 

15 mecanisme de scrutation du bus USB par I'hote. Ce mecanisme est appele 
« polling » dans la terminologie de la specification USB. La recurrence de 
scrutation du bus USB par I'hote, ici I'equipement 30, depend de 
('implementation du protocole du bus USB mise en ceuvre par I'hote. Elle 
resulte d'un compromis entre le temps de latence et la charge du systeme 

20 d'exploitation de I'ordinateur PC qui joue le role de I'hote. Dans la tres grande 
majorite de cas, le systeme d'exploitation est le systeme WINDOWS ® de la 
societe Microsoft Corporation. Dans un exemple prefere, la recurrence de 
scrutation du bus USB par I'equipement 30 est au plus de I'ordre de 10 
millisecondes. 

25 A la figure 3, on a represents le schema fonctionnel d'un module de 

couplage 20. II comprend un coupleur USB 23 pouvant etre relie au bus USB 
31, un coupleur CAN 24 relie a la prise de diagnostic 21 du bus CAN 11, ainsi 
qu'un microcontroleur 22. Le microcontroleur 22 est pilote par un logiciel de 
traitement. Les coupleurs 23 et 24 peuvent §tre des composants independants, 

30 dedies a la fonction de couplage d'un dispositif ou d'un systeme electronique 
quelconque a un bus USB ou a un bus CAN respectivement. Dans le jargon de 
Thomme du metier, on parle de controleur de bus sans unite centrale (dits 
« Stand-Alone » en anglais) pour designer de tels composants. Toutefois, on 



JSDOCID: <FR 2812437A1_L> 



,10 



2812437 



peut avantageusement utiliser un microcontroleur 22 ayant soit un coupleur 
USB soit un coupleur CAN integre (de tels microcontroleurs sont actuellement 
disponibles sur le marche) et en outre un controleur de bus CAN ou un 
controleur de bus USB respectivement. On peut aussi envisager Putilisation 
5 d'un microcontroleur ayant a la fois un coupleur USB et un coupleur CAN 
integres, bien qu'un tel composant ne soit pas semble-t-il, disponible a ce jour, 
et doive done etre fabrique specifiquement. 

Le module de couplage comprend en outre une premiere memoire 
tampon 26 par laquelle transient les donnees en provenance ou a destination 

10 du bus CAN 11 via le coupleur CAN 24, et une seconde memoire tampon 27 
par laquelle transitent les donnees._en .provenance ou a destination du bus USB 
via le coupleur USB 23. II comporte en outre des moyens de controle de flux 
permettant d'eviter la saturation du module de couplage, soit dans le cas de 
trames re?ues du bus CAN (sens reception CAN), soit dans le cas de trames a 

15 envoyer sur le. bus CAN (sens emission CAN). II s'agit de moyens logiciels qui 
font partie du logiciel de traitement. Ces moyens g§n6rent le cas echeant des 
informations de controle de flux (champ ROS, ROI, RFS et TFS sur lesquels on 
reviendra plus loin) qui sont transmises via la liaison bidirectionnelle entre les 
« endpoints » 0 respectifs du module de couplage 20 et de I'equipement 30). 

20 Ces memoires tampon sont par exemple constitutes par des registres 
memoires du microcontroleur 22. Leur taille depend du debit sur le bus CAN et 
de la recurrence de scrutation du bus USB par I'equipement 30. Avec un debit 
sur le bus CAN de I'ordre de 600 Kbits/s, et pour une recurrence de scrutation 
egale a 10 millisecondes, chaque memoire tampon doit pouvoir stocker un 

25 - maximum theorique d'environ 500 octets. Le reste de la memoire du 
microcontroleur est disponible pour la memorisation non volatile du logiciel de 
traitement. 

Une trame CAN est une sequence d'etats electriques (recessifs ou 
dominants) sur la ligne differentielle constituant le bus CAN. Chaque trame 
30 CAN possede un en-tete et de 0 a 8 octets de donnees. Elle a done une 
longueur variable. Le nombre d'octets de donnees est indique dans un champ 
de I'en-tete appele champ DLC (de I'angiais « Data Length Code »). L'origine 
d'une trame est reperee par un champ particulier de I'en-tete appele 
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identificateur et note ID. La version V2.0A de la norme CAN (version standard) 
regit les implementations du protocole du bus CAN avec des identificateurs 
codes sur 1 1 bits. La version V2.0B de la norme CAN (version etendue) regit 
les implementations du protocole du bus CAN avec des identificateurs dont le 
5 format peut etre etendu de 11 bits a 29 bits. La version etendue V2.0B est un 
sur-ensemble de la version standard V2.0A. Dans la suite, le format 
d'identificateur sur 1 1 bits sera note S et le format d'identificateur sur 29 bits 
sera note X, sachant que les deux formats peuvent etre appeles a cohabiter 
selon ('implementation du protocole du bus CAN retenue. Un bit IDE determine 
10 le format S ou X de I' identificateur ID. 

Le destinataire d'une trame CAN n'est pas code. Toutefois il existe un 
mode de transmission particulier, appele mode a distance (« remote » en 
anglais) dans la terminologie de la norme CAN, dans Jequel - un abonne 
demande la transmission de trame a un autre abonne par I'envoi d'une trame 
15 sans donnees, qui est marquee specialement. Ce marquage se fait par un bit 
de I'en-tete, dit bit RTR (de I'anglais « Remote Transmission Request ») qui 
determine le type de la trame (normal ou « remote »). Une trame CAN vehicule 
des informations qui peuvent etre classees en quatre categories differentes en 
fonction de leur nature : 
20 - des donnees, c'est a dire des informations applicatives transitant en 

meme temps que les donnees utiles ; 

- des commandes, c'est a dire des informations de configuration a 
destination du dispositif de couplage de chaque abonne, qui ne sont 
transmises qu'une seule fois a I'initialisation du bus CAN ; 
25 - des informations d'etat, c'est a dire des informations sur I'etat du bus 

CAN ou du systeme de coulage des abonnes et qui necessitent une reaction 
des autres abonnes. 

On va maintenant decrire la facon dont une trame CAN est encapsulee 
dans un ou plusieurs paquets USB selon I'invention. La norme CAN ne 
30 concerne que les couches 1 et 2 du modele de reference pour I'interconnexion 
des systemes ouverts (modele OSI). Toutes les autres couches de ce modele 
font partie du niveau utilisateur. C'est pourquoi, on s'attachera dans un premier 
temps a mettre en evidence les informations qui sont necessaires a la 
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constitution d'une liaison selon le protocole du bus CAN entre I'equipement 30 
et les autres abonnes du bus CAN a savoir les calculateurs 10. Puis, dans un 
deuxieme temps, on presentera un exemple d'encapsulation de ces 
informations dans des paquets USB qui est proposee dans un mode de 

5 realisation prefere. 

Dans ce qui suit, on presente de maniere succincte, a I'aide de tables, 
les champs d'information des trames CAN, chaque table regroupant des 
champs d'information relatifs a des fonctionnalites respectives du protocole du 
bus CAN. Dans chaque table, la premiere colonne (celle de gauche) indique le 

10 nom d'un champ, la deuxieme colonne indique le type d'information porte par 
ce champ, la troisieme colonne indique la nature de cette information, la 
quatrieme colonne indique les valeurs possibles que peut prendre ce champ 
alors que la derniere colonne indique le nombre de bits alloues a ce champ. 

Concernant la fonctionnalite de description des trames CAN, les champs 

15 d'information pertinents sont donnes par la table I ci-dessous. Ces champs ont 
ete introduits plus hgut.et il n'est pas utile de s'etendre plus longuement sur 
leur description. 



Nom 


Information 


Nature 


Valeurs possibles 


Nbre de 
bits 


IDE 


Format de 
I'identificateur 


donnee 


SouX 


1 


RTR 


Format de trame 


donnee 


normale ou « remote » 


1 


DLC 


Nbre d'octets de 
donnees 


donnee 


0a8 


4 


ID 


Idehtificateur 


donnee 


0a 

7FFWSV1 FFFFFFh(X) 


11(S)/29(X) 


D1-D8 


Donnees utiles 


donnee 


quelconques 


'DLC 4 x 8 



20 

TABLE I 

Concernant la fonctionnalite de filtrage des trames, les champs 
25 d'information pertinents sont donnes par la table II ci-dessous. La norme CAN 
introduit des possibilites de filtrage des trames a partir des valeurs des 
identificateurs. Le mecanisme de filtrage consiste a comparer I'identificateur 
d'une trame re?ue a un code d'acceptation p re-programme, puis a eliminer les 
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bits non pertinents grace a un masque d' acceptation. Des paires code/masque 
d'acceptation peuvent etre mises en serie pour augmenter la capacite de 
fiitrage. Dans la table II, on admet la possibility de quatre telles paires au 
maximum. II existe done quatre champs AC1 a AC4 de huit bits chacun pour 
5 coder les codes d'acceptation, et quatre champs AM1 a AM4 de huit bits 
chacun pour coder les quatre masques d'acceptation. La correspondance entre 
les bits du code et les bits de la trame est dependante de ('implementation. 



Nom 


Information 


Nature 


Valeurs 
possibles 


Nbre de 
bits 


ACB 


Controle de 

-['acceptation 


commande 


depend de 
- ('implementation 


8 


AC1-*4 


Codes d'acceptation 


commande 


depend de 
('implementation 


4x8 


AM1— >4 


Masques 
d'acceptation 


commande 


depend de 
rimplementation 


4x8 


AH 


N° d'acceptation 


donnee 


0a7 


3 



10 

TABLE II 

Concernant la fonctionnalite de gestion des erreurs, les champs 
d'information pertinents sont donnes par la table III ci-dessous. 

15 Les etaits d'erreurs d'un abonne CAN sont hierarchises en quatre 

categories qui induisent des comportements de moins en moins actifs pour 
I'abonne. Selon la terminologie de la norme CAN, on distingue ainsi I'etat « error 
active », I'etat « error warning », I'etat « error passive », et I'etat « bus off » dans 
lequel I'abonne est deconnecte du bus CAN. Les transitions entre ces etats se 

20[ font par comparaison de la valeur d'un compteur d'erreurs a des seuils. Pour 
chaque abonne CAN, II y a un compteur d'erreurs en emission et un compteur 
d'erreurs en reception. Ainsi, un abonne CAN se trouve dans I'etat « error 
active » pour les valeurs du compteur comprises entre 0 et 95, dans I'etat « error 
warning » pour les valeurs du compteur comprises entre 96 et 127, dans I'etat 

25 « error passive » pour les valeurs du compteur comprises entre 128 et 255, et 
dans I'etat « bus off » pour les valeurs du compteur superieures a 255. 
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Nom 


Information 


Nature 


Valeurs 
possibles 


Nbre de 
bits 


REC 


Compteur cTerreurs en reception 


etat 


quelconque 


8 


TEC 


Compteur d'erreurs en emission 


etat 


quelconque 


8 


WT 


Seuil divertissement 


commande 


1-127 


8 


RWS 


Etat divertissement en 
reception 


eiai 


normal / wflrninn 


i 
i 


TWS 


Etat divertissement en 
emission 


etat 


normal / warning 


1 


RPS 


Etat « Error passive » en 
reception 


etat 


normal / error 
passive 


1 


TPS 


Etat « Error passive » en 
emission 


etat 


normal / error 
passive 


1 


BOS 


Etat bus deconnecte 


etat 


normal / bus off 


1 


CDC 


CT+/->+ rid r~\r\c?\t\r\r> H'orroi ir 
.tIaI,Qft_j-?OblU.O[Ly ."J » yUl. 


etat 


depend de 
('implementation 


8 


RWI 


Alerte avertissement en 
reception 


alerte 


norma! / warning 


1 


TWI 


Alerte avertissement en 
emission 


alerte 


normal / warning 


1 I 


RPI 


Alerte passive en reception 


alerte 


normal / passive 


1 


TPI 


Alerte passive en emission 


alerte 


normal / passive 


1 


BOI 


Alerte bus deconnecte 


alerte 


normal / bus off 


1 



TABLE 111 

5 

Concernant les fonctionnalites liees aux caracteristiques temporelles du 
protocole, les champs d'information sont donnes par la table IV ci-dessous. 

II faut distinguer d'une part le cadencement des bits, la definition du point 
d'echantillonnage, et la resynchronisation, d'autre part la vitesse de transfert, et 
10 enfin le marquage temporel. 

Dipres la norme CAN, la duree d'un bit est divisee en quatre segments, 
appeles, « synchro », « propagation », « phase 1 », et « phase 2 ». L'etat du bus 
est echantillonne entre les segments « phase 1 » et « phase 2 ». La duree des 
segments est programmable (champs TS1 et TS2) comme un multiple d'une 
15 duree de base appelee quantum. En cas de derive d'horloge d'un abonne a 
Tautre, un saut de resynchronisation a lieu sur les segments « phase 1 » et/ou 
« phase 2 ». Ce saut a une largeur programmable (champ RJW) comme un 
multiple du quantum. 
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La vitesse de transfert est definie par la duree du quantum. Celle-ci 
depend du nombre de quanta programme dans un bit. Cette duree est derivee 
de la frequence d'horloge du systeme, a travers un pre-diviseur programmable 
(champ PSR) reduisant la frequence. La norme CAN permet d'atteindre des 
5 debits allant jusqu'a 1Mbit/s. Cependant la grande majorite des applications 
necessite actuellernent des vitesses de transfert comprises entre 125 Kbit/s et 
500 Kbit/s. 

Dans certaines applications, il est necessaire de dater I'arrivee des trames 
CAN par rapport a un chronometre local. On parle de marquage temporel car 
10 chaque trame CAN re?ue est alors marquee par la valeur du chronometre au 
. moment -de- sa reception. L'unite de temps du marquage temporel (champ TSU) 
depend de rimplementation. Cette fonctionnalite est reperee par un bit determine 
appele bit TSC. 



Nom 


Information 


Nature 


Valeurs 
possibles 


Nbre de 
bits 


PSR 


Valeur de predivision 


commande 


depend de 
rimplementation 


8 


TS1 


Duree du segment phase 
1 


commande 


depend de 
rimplementation 


8 


TS2 


Duree du segment phase 
2 


commande 


depend de 
rimplementation 


8 


SYS 


Etat de synchronisation 


Stat 


synchro / non 
synchro 


1 


SN 


Nombre d'echantillon 


commande 


simple / multiple 


1 


RJW 


Largeur du saut 
resynchronisation 


commande 


depend de 
rimplementation 


8 


TSC 


Controle de marquage 
temporel 


commande 


normal / 
marquage 


1 


TSU 


Unite de marquage 


commande 


depend de 
rimplementation 


8 


TSW4 


Valeur du chronometre 


donnee 


quelconque 


32(S)/24(X) 



15 

TABLE IV 

Concernant la fonctionnalite de connexion/deconnexion au bus CAN les 
20 champs d'information pertinents sont donnes dans la table V ci-dessous. 

On distingue plusieurs commandes, notamment une demande de 
deconnexion du bus CAN ou de mise en sommeil (bit SR) et une demande de 
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connexion au bus CAN (bit RST). II est possible de detecter le demarrage d'un 
trafic sur le bus CAN par reveil automatique, grace a la surveillance des 
transitions sur le bus CAN. Ces transitions peuvent etre filtrees suivant 
I'implementation du protocole du bus CAN, grace a une commande de filtrage du 
5 reveil (bit WF). Dans certaines applications, et notamment pour le diagnostic 
embarque, il est necessaire de capturer les trames circulant sur le bus CAN sans 
intervenir activement dans le processus de transmission, c'est a dire sans 
emission ni acquittement explicite. Ceci est realise par une commande de lecture 
seule (bit LO). 

10 Chaque abonne du bus CAN doit etre en mesure de verifier par lui-meme 

sa connexion.au. bus. CAN. Pour cela, on prevoit un rnecanisme de rebouclage 
transmission sur reception. On realise ainsi une fonction d'autotest grace a une 
demande de boucle locale (bit LLR). 



Norn 


Information 


Nature 


Valeurs possibles 


Nbre de 
bits 


RST 


Demande de connexion 


commande 


normal / reset 


1 


SR 


Demande de deconnexion 


commande 


normal / sommeil 


1 


WF 


Filtraqe du reveil 


commande 


normal / filtrage 


1 


LO 


Lecture seule 


commande 


normal / lecture 


1 


LLR 


Demande de boucle locale 


commande 


normal / rebouclage 


1 


SLS 


Etat de deconnexion 


etat 


normal / sommeil 


1 


Wl 


Alerte de reveil 


alerte 


normal reveil 


1 



TABLE V 



Concernant la fonctionnalite de controle de flux, les champs d'information 
20 pertinents sont donnes par la table VI ci-dessous. 

Des signaux de controle de flux sont mis en place pour detecter une 
eventuelle saturation .(« overrun » en anglais) d'un abonne CAN soit dans le sens 
reception (bits ROS, ROI et RFS) soit dans le sens emission (bit TFS). Dans le 
sens reception, il est en effet possible que des trames CAN arrivent plus 
25 rapidement que la capacite de lecture du coupleur CAN de I'abonne. II y a alors 
saturation car aucun rnecanisme n'est prevu par la norme CAN pour ralentir 
remission des trames. Dans le sens emission, le probleme de regulation ne se 
pose qu'au niveau du coupleur CAN de I'abonne. En effet I'arrivee des messages 
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a emettre ne doit pas se faire plus rapidement que la capacite d'emission sur le 
bus CAN par le coupleur CAN de I'abonne. 



Nom 


Information 


Nature 


Valeurs 
possibles 


Nbre de 
bits 


ROS 


Etat « overrun » en reception 


etat 


normal / overrun 


1 


ROI 


Alerte « overrun » en reception 


alerte 


normal / overrun 


1 


RFS 


Etat du flot de donnees en 
reception 


etat 


normal / saturation 


1 


TFS 


Etat du flot de donnees en 
emission 


etat 


normal / saturation 


1 



5 TABLE VI 

On va maintenant doriner un exemple d'une maniere d'encapsuler les 
champs d'information ci-dessus d'une trame CAN quelconque, dans au moins un 
paquet USB. De preference, tors de cette encapsulation on regroupe les champs 

10 d'information de la trame CAN selon la nature des informations qu'ils vehiculent, 
parce que ces informations sont transmises sur le bus CAN a des instants 
equivalents. On distingue ainsi des paquets de donnees, des paquets de 
commandes, des paquets d'etats, et des paquets d'alertes. Dans ce qui suit, on 
ne s'interesse qu'aux huit octets de donnees d'un paquet USB, et non a I'en-tete 

15' ni aux bits de detection ou de correction d'erreur de celui-ci. 

Concernant les paquets de donnees, il faut distinguer selon le format 
(standard ou etendu) des identificateurs des trames CAN. Ces paquets circulent 
sur les liaisons logiques entre les points terminaux unidirectionnels 1 a 4. Leur 
longueur depend du format de I'identificateur de la trame CAN, et du nombre 

20 d'octets vehicules. L'octet 0 du paquet USB contient les champs dont les valeurs 
determined le format de la trame. II est independant du format de I'identificateur 
de la trame CAN. Son contenu peut done etre decode de la meme facon pour le 
format standard et pour le format etendu. C'est le bit IDE de cet octet qui identifie 
le format de I'identificateur de la trame CAN. Le champ DLC fournit le nombre 

25 d'octets de donnees de I'en-tete de la trame CAN. Le bit TSC indique la 
presence (TSC = 1) ou I'absence (TSC = 0) des octets de marquage tempore! 
(champs TS1 a TS4). 
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Pour une trame CAN avec un identificateur au format standard (bit IDE = 
0) dont la longueur est comprise entre 3 et 1 1 octets suivant le nombre d'octets 
de donnees (hors octets de marquage temporel) de I'en-tete de la trame CAN, le 
contenu des octets de donnees d'un paquet USB est decrit dans la table VII ci- 
5 dessous : 



bits 


7 


6 


5 


4 


3 


2 1 


0 


Octet 0 : format de trame 


0 


RTR 


IDE 


TSC 


DLC.3 




DLC.O 


Octet 1 : identificateur 


ID.10 












ID.3 


Octet 2 : identificateur + 
succes d'acceptation 


ID.2 


ID.O 


0 


AH.2 


AH.3 


"Octet 3 -=>" 10 : data 1—8 
(1) 


Dn.7 












Dn.O 


Octet 11: marquage 
tempore! 1 (2) 


TS.31 












TS.24 


Octet 1 2 : marquage 
temporel 2 (2) 


TS^23 












TS.16 


Octet 1.3 : marquage 
temporel 3 (2) 


TS.15 












TS.8 


Octet 14 : marquage 
temporel 4 (2) 


TS.7 












TS.O 



(1 ) depend du champ DLC 

(2) presents si bit TSC = 1 

10 

TABLE VII 



15 Pour une trame CAN avec un identificateur au format 

etendu (bit IDE = 1), dont la longueur est comprise entre 5 et 13 octets suivant 
le nombre d'octet de donnees (hors octets de marquage temporel) le contenu 
des octets de donnees d'un paquet USB est decrit dans la table VIII ci-dessous : 



20 



25 
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bits 


7 


6 


5 


4 


3 


2 1 


0 


Octet 0 : format de 
trame 


i 
i 


RTR 


IDE 


TSC 


DLC.3 


DLC.O 


Octet 1 : 
identificateur 


ID.28 








ID.21 


Octet 2 : 
identificateur 


in on 








ID.13 


Octet 3 : 










ID. 5 


identificateur 










Octet 4 : 












identificateur + 


ID.4 




ID.O 


AH.2 


AH.O 


succes 












d'acceptation 












Octet 5 ^12 : 
donnees 5 8 (1) 


Dn.7 








Dn.O 


Octet 13 : marquage 
temporel 1 (2) 


;TS.23 








TS.16 


Octet 14 : marquage 
temporel 2 (2) 


jTS.15 








TS.8 


Octet 15 : marquage 
temporel 3 (2) 


TS.7 








TS.O 



(1) depend du champ DLC 



(2) presents si bit TSC = 1 

5 TABLE V1H 

Les paquets de commande circulent sur les liaisons entre les points 
terminaux unidirectionnels 2 et/ou 4. lis peuvent contenir des informations de 
10 programmation du module de couplage. lis sont done transmis a I'initialisation du 
systeme. On notera que le champ ML, code sur quatre bits, qui est present dans 
I'octet 0, determine le nombre d'octets du paquet USB. Le contenu des octets 
d'un tel paquet USB est decrit par la table IX ci-dessous : 
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bits 


7 


6 


5 


4 


3 


2 


1 u 


Octet 0 : format de trame 


1 


0 


1 


1 


ML3 




MLO 


Octet 1 : clivers 


SN 


WF 


LO 


LLR 


TSC 


o 


n I DOT 

SR I RST 


Octet 2 : valeur de 
predivision 


PSR.7 












PSR.O 


Octet 3 : duree du 
seqment 1 phase 


TS1.7 












TS1.0 


Octet 4 : duree du 
seament 2 phase 


TS2.7 












TS2.0 


Octet 5 : iargeur du saut 
de ^synchronisation 


RJW.7 












RJW.O 


Octet 6 : seuil 
d'avertissement 


WT.7 














WT.O 


Octet 7 : unite de 
marquaqe temporel 


TSU.7 












TSU.O 



TABLE IX 



Un paquet de commande peut aussi contenir des informations de 
5 filtrage des trames CAN. Dans ce cas, le contenu de ces octets est decrit dans la 
table X ci-dessous : 



bits 


7 


6 


5 


4 


3 


2 


1 I 0 


Octet 0 : format de 


1 


0 


1 


1 


ML3 




MLO 


trame 












Octet 1 : octet de 
controle d' acceptation 


ACB.7 




ACB.O 


Octet 2 : code 
d'acceptation 1 


AC1.7 




AC1.0 


Octet 3 : masque 
d'acceptation 1 


AM1.7 




AM 1.0 


Octet 4 : code 
d'acceptation 2 


AC2.7 




AC2.0 


Octet 5 : masque 
d'acceptation 2 


AM2.7 




AM2.0 


Octet 6 : code 
d'acceptation 3 


AC3.7 




AC3.0 


Octet 7 : masque 
d'acceptation 3 


AM3.7 




AM3.0 


Octet 8 : code 
d'acceptation 4 


AC4.7 




AC4.0 


Octet 9 : masque 
d'acceptation 4 


AM4.7 




AM4.0 



10 TABLE X 
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Un paquet de commande USB peut encore contenir des 
informations d'interrogation du module de couplage. Un paquet d'etat sera alors 
transmis par celui-ci en reponse a ce paquet d'interrogation. Un tel paquet 
d'interrogation ne contient qu'un octet, a savoir I'octet 0 dont le contenu est d6crit 
5 par la table XI ci-dessous : 



bits 


7 


6 


5 


4 


3 


2 


1 0 


Octet 0 : format de trame 


1 


0 


1 


0 


ML.3 




ML.O 



10 TABLE XI 

Un message d'etat circule sur les liaisons entre les points de terminaison 
unidirectionnels 1 et/ou 3. II contient des informations sur. . Petat du module de 
1 5 couplage. II est envoye en reponse au message d'interrogation decrit ci-dessus. 
Le contenu des octets d'un paquet USB pour la transmission d'un tel message 
est donn6 par la table XII ci-dessous : 



bits 


7 


6 


5 


4 


3 


2 


1 


0 


Octet 0 : format de 
trame 


1 


0 


1 


1 


ML3 






MLO 


Octet 1 : divers 


RWS 


TWS 


RPS 


TPS 


BOS 


OVS 


SYS 


SLS 


Octet 2 : compteur 
d'erreurs de reception. 


REC.7 












REC.O 


Octet 3 : compteur 
d'erreurs d'emission 


TEC.7 












TEC.O 


Octet 4 : position erreur 


EPS. 7 












EPS.O 



20 

TABLE XII 

25 Enfin, un message d'alerte circule entre les points de terminaison 

unidirectionnels 1 et/ou 3. II contient des informations sur des evenements 
asynchrones survenant dans le module du couplage. Le contenu des octets d'un 
paquet USB pour la transmission d'un tel message d'alerte est donne par la table 
XIII ci-dessous : 

30 
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bits 


7 


6 


5 


4 


3 


2 


1 


0 


Octet 0 : format de 
trame 


1 


1 


0 


0 


ML.3 


ML.O 


Octet 1 : alertes 


RWI 


TWI 


RPI 


TPI 


BOI 


OVI 


0 


Wl 


Octet 1 : etats 


RWS 


TWS 


RPS 


TPS 


BOS 


OVS 


SYS 


SLS 



TABLE Xlll 



Au point de vue du protocole d'echange, la scrutation du bus USB 
par Tequipement 30 se fait a intervalles de temps reguliers tant qu'il n'y a pas de 
donnees transmises sur le bus. Lorsque la transmission d'un flot de donnees sur 
le bus USB est amorcee, la scrutation est interrompue jusqu'a ce que ia memoire 
tampon de reception de Tequipement 30 soit vide. 

Du point du vue de Tequipement 30, le controle de flux est realise de la 
fagon suivante. En reception, le champ RFS indique Tetat normal ou sature de 
Tequipement 30. Si Tequipement 30 est sature, le flot de donnees transmis 
depujs le module de couplage 20 vers Tequipement 30 doit etre momentanement 
suspendu par le module de couplage 20. Les messages OBD sont alors stockes 
dans la memoire tampon 27 du module de couplage 20. En emission, la valeur 
du champs TFS indique Tetat normal ou sature du module de couplage 20. Si 
celui-ci est sature, le flot de donnees transmis depuis Tequipement 30 doit etre 
momentanement suspendu. Les message OBD sont alors stockes dans une 
memoire tampon de Tequipement 30. Les champs RFS et TFS sont transmis par 
des messages ad-hoc dans des paquets USB sur la liaison entre les points 
terminaux bi-directionnels 0. 

Pour un debit sur le bus CAN egal a 600 Kbits/s environ, le taux de 
transfert utile maximum est de 35,2 Ko/s en format standard et de 29,8 Ko/s en 
format etendu. Compte tenu de la taille des paquets USB (sans les octets de 
rnarquage tempore!), le taux de transfert brut maximum theorique devient egal a 
48,4 Ko/s, quel que soit le format de Tidentificateur des trames CAN. Ce taux de 
transfert ne represente qu f une charge tres faible pour le bus USB (de Tordre de 
3,3 % de la charge maximale theorique du bus USB). 
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REVENDICATIONS 

1. Procede de communication entre un equipement (30) exterieur a un 
5 vehicule automobile (1) d'une part et des calculateurs embarques (10) relies 

entre eux par au moins un bus CAN (11) d'autre part, comprenant les 6tapes 
consistant a ; 

- encapsuler, au niveau de I'equipement (30) ou au niveau d ! un module de 
couplage (20) connecte d'une part au bus CAN (11) de maniere a eviter la 

10 generation de reflexions electriques sur celui-ci et d'autre part a un bus USB 
(31), une trame CAN emise selon le protocole du bus CAN par I'equipement (30) 
ou par un calcuiateur respectivement, dans au moins un paquet USB selon le 
protocole du bus USB ; 

- emettre, via le bus USB (31), le paquet USB vers le module de couplage 
15 (20) ou vers I'equipement (30) respectivement ; 

- recevoir, au niveau du module de couplage (20) ou au niveau de 
I'equipement (30) respectivement, le paquet USB et le decapsuler pour en 
extraire la trame CAN, 

en sorte qu'un programme d'application s'executant dans I'equipement 
20 (30) est vu sur le bus CAN (1 1 ) comme un abonne CAN. 

2. Procede selon la revendication 1 ou la revendication 2 dans lequel, lors 
de ['encapsulation, on regroupe les champs d'information de la trame CAN selon 
la nature des informations qu'ils vehiculent. 

25 

3. Procede selon la revendication 1, dans lequel, du point de vue du bus 
USB, I'equipement (30) est I'hote alors que le module de couplage (20) est un 
dispositif fonctionnel/ 

30 4. Procede selon Tune des revendications precedentes, dans lequel le 

mode de transfert selectionne sur le bus USB (31) est le mode dit "bulk". 
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5. Procede selon I'une des revendications precedentes, dans lequel la 
recurrence de scrutation du bus USB (31) par Tequipement (30) est au plus de 
I'ordre de 10 millisecondes. 

5 6. Dispositif de communication entre un equipement (30) exterieur a un 

vehicule automobile (1) d'une part et des calculateurs embarques (10) relies 
entre eux par au moins un bus CAN (11) d'autre part, dans lequel 
Tequipement (30) est connecte a un bus USB (31), le dispositif comprenant un 
module de couplage (20) connecte d'une part audit bus CAN (11) de maniere a 

1 0 eviter la generation de reflexions electriques sur celui-ci et d'autre part audit bus 
USB (31), et comprenant des moyens pour transmettre, via le bus USB, des 
trames CAN entre I'equipement (30) et les calculateurs (10) de maniere qu'un 
programme duplication s'executant dans I'equipement (30) est vu sur le bus 
CAN (1 1 ) comme un abonne CAN. 

15 

7. Dispositif selon la revendication 6, dans lequel le module de couplage 
comprend des moyens pour la mise en oeuvre d'un procede selon I'une des 
revendications 1 a 5. 

20 8. Dispositif selon la revendication 6 ou la revendication 7, dans lequel, du 

point de vue du bus USB (31), I'equipement (30) est I'hote alors que le module de 
couplage (20) est un dispositif fonctionnel. 

9. Dispositif selon I'une des revendications 6 a 8, dans lequel le mode de 
25 transfert sur le bus USB (31 ) est le mode dit "bulk". 

10. Dispositif selon I'une des revendications 6 a 9, dans lequel la 
recurrence de scrutation du bus USB (31) par I'equipement (30) est au plus de 
I'ordre de 10 millisecondes. 



30 



11. Dispositif selon I'une des revendications 6 a 10, dans lequel le module 
de couplage (20) est connecte au bus CAN (1 1 ) par I'intermediaire d'une prise de 
diagnostic (21) situee a une extremite (12) du bus CAN. 
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12. Dispositif selon Tune quelconque des revendication 6 a 11, dans 
lequel le module de couplage (20) est connecte au bus USB (31) de maniere a 
etablir deux liaisons logiques entre une paire de points terminaux 

5 unidirectionnels de I'equipement (30) et la paire de points terminaux 
unidirectionnels correspondante du module de couplage (20). 

13. Dispositif selon Tune quelconque des revendications 6 a 11, dans 
lequel les calculateurs (10) sont relies par deux bus CAN (11a ; 11b), et dans 

10 lequel un premier module de couplage (20a) est connecte d'une part au premier 
bus CAN (11a) et d'autre part au bus USB (31) de maniere a etablir deux liaisons 
logiques entre une premiere paire de points terminaux unidirectionnels de 
I'equipement (30) et la paire de points terminaux unidirectionnels 
correspondantes du premier module de couplage (20a) a raison d'une liaison par 

15 sens de transmission, alors que le . second module de couplage (20b) est 
connecte d'une part au second bus CAN (11b) et d'autre part au bus USB (31) de 
maniere a etablir deux autres liaisons logiques entre une seconde paire de points 
terminaux unidirectionnels de I'equipement (30) et la paire de points terminaux 
unidirectionnels correspondantes du second module de couplage (20b) a raison 

20 d'une liaison par sens de transmission. 

14. Dispositif selon la revendication 13, dans lequel chaque point terminal 
unidirectionnel est programme en sorte que la taille des paquets USB qu'il delivre 
ou collecte soit egale a 16 octets. 

25 

1 5. Dispositif selon Tune quelconque des revendications 6 a 14, dans 
lequel le module de couplage (20 ; 20a ; 20b) est alimente par Pintermediaire du 
bus USB (31 ; 31a ;31b). 

30 16. Dispositif selon Tune quelconque des revendications 6 a 15, dans 

lequel le module de couplage (20) comprend une premiere memoire 
tampon (26) par laquelle transient les donnees en provenance ou a destination 
du bus CAN (1 1) et une seconde memoire tampon (27) par laquelle transient les 
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donnees en provenance ou a destination du bus USB (31), et des moyens de 
controle de flux pour eviter la saturation de I'un et I'autre bus. 

17 Dispositif selon Tune quelconque des revendications 6 a 16, dans 
lequel le module de couplage (20) comprend un microcontroleur (22) contenant 
un coupleur USB (23) et/ou un coupleur CAN (24) integres. 

18. Systeme de diagnostic embarque pour vehicule automobile (1) 
comprenant 

- des calculateurs embarques (10), relies entre eux par au moins un bus 
CAN (11 ; 11a ;11b) et pouvant envoyer ou recevoir par. lMntermediaire dudit bus 
CAN (11 ; 11a ;11b) des messages de diagnostic embarque sous la forme de 

trames CAN ; ■' 

-une station de diagnostic (30) exterieure au vehicule automob.le (1), 

15 reliee a un bus USB (31); 

-un dispositif de communication selon Tune quelconque des 
revendications 6 a 17, de maniere qu'un programme d'application s'executant 
dans la station de diagnostic (30) est vu sur le bus CAN (11 ; 11a ;11b) comme 
un abonne CAN. 



10 
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FIG. 3. 
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